An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hi Everyone, I really hate to be that guy but I was wondering if anyone else has been waiting as long as I have to get their app reviewed? I have an app that I put up for review July 30th and now we're on the 12th day waiting. (By the way, if you are an apple employee and you happen to see this message and want to help, the app is called Sudoku Every Day - Paper & Pen and the submission ID is f6750769-9018-4236-b413-ea07bc05d907). I know they are experiencing a backlog right now, and I've been patient understanding that. I guess I'm just a little frustrated because I see people on social media who supposedly put their app in after me that have already been approved, although I get that that's just random luck of the draw probably. Do you all think it's possible my app is stuck though? Should I request an expedited review? I kind of don't want to do that just because I bet everyone is doing that with the backlog and I don't believe I qualify for it. I do have a big update ready since I've added a lot of variants to my app in the last few weeks. That's ready to go but that's not really time critical ..... Another thing I was wondering is could this have something to do with the fact that I first tried to submit it after building in Xcode 27 beta? The beta builds kept getting auto-rejected so I had to eventually submit a build that I made on another computer (MacOS 26.6/Xcode 26.6) to get it to be accepted into review but that was the 6th build. Is there a chance my previous builds getting auto-rejected put me on some slow train to app review? Just curious to hear others experiences. If you made it all the way to the end of this, thanks for reading! -E

Hello, Our app was submitted on August 7 and has remained in “Waiting for Review” with no status change. This is now a launch-blocking issue for a scheduled enterprise customer rollout on August 13. Hundreds of participants are already scheduled for mobile user testing and are unable to proceed without the iOS app. We have submitted an expedited review request and contacted Developer Support, but have not received a response or any update from either channel. At this point, the App Review delay is directly blocking a committed enterprise launch and participant testing schedule. We would greatly appreciate any urgent assistance in getting this case reviewed or escalated to the appropriate App Review team. App Name: Satellica App Apple ID: 6797731123 Submission ID: b7105850-5a17-489d-907d-550febe3895a Thank you.

Hello, I am experiencing an unusually long wait for the first submission of my iOS app. App Store Connect details: Platform: iOS Version: 1.0 First submission for this app First submission for my developer account Current submission date: July 30, 2026 at 21:11 Current status: “Waiting for Review” Apple ID: 1413120388 The submission has now been in “Waiting for Review” for 12 days and has never moved to “In Review”. There are no messages in the Resolution Center and I have not received any request for additional information. The previous submission, made on July 28, was removed by me. The current submission is the new submission from July 30. The app is a fairly complex collaborative social application centered around maps, including shared geo-organizers and collaborative elements. I understand that review times can vary, especially for a first submission and for a more complex application. I am not requesting an expedited review. I would simply like to ask whether the current submission is correctly queued for App Review, or whether there might be an issue preventing the review from starting. Any guidance would be greatly appreciated. Thank you.

I submitted my first public build (iOS 1.0) on July 30th for my game, Golfer's Pair-A-Dice (Apple ID: 6789222313) and it has been in "Waiting for Review" with no movement since then. I read that 24-48 hours is typical, but could take longer for first builds, but it seems like it hasn't even begun to be reviewed which is frustrating. Has anyone experienced similar wait times in the queue and had any success getting their app reviewed? I was hoping to launch on App Store and Google Play Store at same time and Google approved the app in 2 days so it has just been waiting for me to push, which I am waiting on Apple to approve so I can push both simultaneously.

Hello Developer Community, We have submitted our brand new app to the app store that many people worked really hard on. We have been waiting anxiously to see what apple says. However, the app never leaves the "waiting to be reviewed" state, and it has been more than a week since we have uploaded it. We know Apple put back to the queue if we update build and we haven't made any update. Why its taking too long. We have committed a date our clients it will on App Store by 5th Aug (submitted on 30th July) but no work from Apple yet. Now its creating question on crediblity us from our clients.

Hello App Review Team, Our iOS app has been stuck in "Waiting for Review" for more than 12 days with no status change and no Resolution Center messages. App name: Express Evaluations Developer: Express Evaluations, Inc Platform: iOS Version: 1.0 Current status: Waiting for Review Submitted: July 30, 2026 at 11:52 AM We opened an App Review Status case on August 10, 2026 and have not received a reply yet. Case ID: 20000133168856 This delay is blocking our planned release and is affecting stakeholder trust in our launch timeline. Could someone from App Review please check whether this submission is stuck in the queue and advise on the current status? Thank you for your help.

Hi everyone, My app just received a rejection citing Guideline 3.1.2(c) - Business - Payments - Subscriptions: "The auto-renewable subscription promotes the free trial, introductory pricing, or introductory period for the subscription more clearly and conspicuously than the billed amount." Does anyone have advice on how to resolve this? I am currently using "Try for Free" as the main CTA button to activate the trial, which seems to be a common industry practice. Any insights would be greatly appreciated!

Hi Apple Developer Community, Our first iOS release (Version 1.0) has been stuck in “Waiting for Review” since August 7 with no status change. We have already submitted an expedited review request due to a critical, time-sensitive business need this week. We have also tried contacting Apple Developer Support through multiple channels. We requested a phone callback but have been waiting for over six hours without being connected, and we have not yet been able to reach the support team. Could someone from Apple please advise whether there may be an issue with the submission, or whether there is any additional action we should take to help move the review forward? Any guidance or assistance would be greatly appreciated. Thank you.

Our app Broons Tea Room (App ID: 6795576807) has been waiting for review for more than 10 days. We have also submitted an expedited review request, but we haven't received any update yet. Could you please check the status of our app and help expedite the review if possible? Please let us know if you need anything from our side. Thank you for your help.

Hello Apple App Review Team, Our app Broons Tea Room (App ID: 6795576807) has been waiting for review for more than 10 days. We have also submitted an expedite review request, but we haven't received any update yet. Could you please check the status of our app and help expedite the review if possible? Please let us know if you need anything from our side. Thank you for your help.

Hi Apple Developer Community, Our app has been waiting for App Review for around 15 days, and we still haven't received any update or response from the App Review team. The app was submitted for review on July 26, 2026, and it has remained in the "Waiting for Review" status since then. We have also tried contacting the appropriate support/contact team, but unfortunately, we haven't received a response there either. This is blocking our production release and affecting our customers who are waiting for the app. Could anyone advise what we should do in this situation or how we can escalate the review? Bundle Ids: com.sanisetu.supervisor / com.sanisetu.worker Submission Date: July 26, 2026 Current Status: Waiting for Review Time Waiting: ~15 days Any guidance would be greatly appreciated. Thank you.

Our app — a screen-time / focus app — has had no App Review activity for two weeks, and we believe the trigger was an automated Guideline 2.5.1 check that froze an otherwise actively progressing review. (This forum account is linked to the developer account in question; we can provide the App ID, bundle IDs, submission IDs, and support case numbers through any private channel on request.) Context: Jul 2–5: Our first submission (Version 1.0.0) was under active review. We went through several ordinary metadata / paywall-related iterations, and the reviewer responded within roughly 24 hours each time. Nothing related to Screen Time was raised in these human reviews of builds 9 and 10. Jul 8: After we submitted build 11 — which addressed the remaining human-review feedback — we received an automated Guideline 2.5.1 (Performance: Software Requirements) message stating that the app uses the Screen Time API but has not been submitted with the Family Controls entitlement, and that review of the submission cannot proceed. All reviewer activity stopped at that point, and there has been none since. What we verified: The Family Controls (Distribution) entitlement is granted to our account and assigned to all four bundle IDs (the main app plus its DeviceActivityMonitor, ShieldAction, and ShieldConfiguration extensions). We verified with codesign that com.apple.developer.family-controls = true is present in the code signature and embedded provisioning profile of every one of the four executables in the submitted IPA — so the entitlement named in the automated message is present in the flagged build. For context: builds 9 and 10, with an identical Screen Time API surface and identical entitlements (verified at the binary level with nm against the submitted artifacts), had been human-reviewed on Jul 2–5 with no Screen Time-related objection. We recognize those builds may simply not have reached the automated analysis stage before being superseded, so we do not draw firm conclusions from that. What we did anyway (build 12, submitted Jul 9): In case the automated check actually concerns the separate com.apple.developer.family-controls.app-and-website-usage entitlement (which we do not request and do not need), we removed every reference from our main app to the APIs associated with it: AuthorizationStatus.approvedWithDataAccess, ManagedSettings.Application.bundleIdentifier, ManagedSettings.Application.localizedDisplayName, ManagedSettings.ActivityCategory.localizedDisplayName, and ManagedSettings.WebDomain.domain. We verified with nm that none of the four executables in the build 12 IPA reference these APIs. The app does not use FamilyActivityData, DeviceActivityReport, app usage events, web usage events, or App and Website Usage data access. No automated message has appeared for build 12. What has happened since: Jul 9–14: No reviewer activity on build 12. We filed an expedited review request and opened two Developer Support cases (Jul 8 and Jul 14). No response to any of them. Around Jul 15: Hoping to clear the frozen state, we cancelled and resubmitted the same Version 1.0.0 / build 12. Around Jul 17: Filed a second expedited review request for the new submission. Jul 22 (today): The new submission has been in "Waiting for Review" since Jul 15, with no reviewer activity and no reply to either support case or either expedite request. What we are asking: Could someone check whether the Jul 8 automated flag is still attached to the app record and blocking reviewer assignment, and help get the current submission assigned to a reviewer? If the automated check flags build 12 again, could the message specify which entitlement and which binary / API references triggered it, so we can address it precisely? We can provide codesign output, entitlement plists, provisioning profile dumps, and nm symbol listings on request. Thank you.

Hello, Our app has been in "Waiting for Review" since August 2, 2026 with no status change and no communication. App name: Matchup Sport Apple ID: 6782085896 Bundle ID: app.matchupsports.matchup Build: 1.0.0 (38), uploaded July 29, 2026 Submitted: August 2, 2026 Support case: 20000129837883 (opened August 6, no resolution) What we have already verified on our side: Build 38 shows Validated and passed beta review for external TestFlight; it is currently distributed to external testers with sessions logged and no crashes reported All metadata is complete: description, keywords, screenshots, promotional text Support URL and Marketing URL are live and reachable A working demo account is provided in App Review Information along with review notes Export compliance is answered (App Uses Non-Exempt Encryption: No) Paid Apps Agreement and Free Apps Agreement are Active; tax forms are Active DSA trader status is declared at both account and app level This is the first submission on this developer account. I would like to confirm that nothing is blocking the submission from entering review, and whether any action is required from our side. Thank you.

Hi everyone, My app has been stuck in “Waiting for Review” for about 10 days, and I’m wondering if anyone has experienced something similar recently. Details: Submission ID: 0f5f47ab-fa7e-4def-a1ae-d1d23665289c Submitted: August 1, 2026 There hasn’t been any update or message from App Review so far. Is this kind of delay normal, or should I contact Apple Developer Support? I’m also wondering if cancelling and resubmitting would help, or if that could make the wait even longer. Thanks for any advice or experience you can share.

Our app Blobber (id 6791237124) launched on the App Store on August 2. Version 1.0 shipped with a critical bug: the Attention report — a core feature on the app's main screen — stays locked showing "Screen Time needed" even after the user grants Screen Time permission. Every new download is affected and there is no workaround in 1.0. We submitted the fix (1.0.1, a single-bug release) on August 5. Six days later it is still "Waiting for Review". Version 1.0 was consistently reviewed within 24–48 hours in July, so this delay is unusual for our account, and it lands squarely in our launch window while every new user hits a broken core feature. Is there anything beyond the standard expedited review request we can do to get movement on this? Has anyone else seen multi-day "Waiting for Review" queues recently?

App Name: OurHouse App ID: 919471395 We turned in a very necessary update Tuesday August 4th. Heard back from Apple that we got rejected for keywords in our metadata that we've been using successfully for 5+ years and never changed. Those same keywords were used for a submission as recently as 3 weeks ago that went through with no issues. We were told this at 10:44PM PST by 11:14PM my team responded asking what keywords specifically were violating guidelines and it's been complete radio silence since then. We even removed any and all keywords and resubmitted, and now our App has been stuck in review for 6 days. I am pleading for help, I've been stonewalled by every department and cannot reach Apple Review. As I'm writing this I've been waiting for 3 hours for an advisor or anyone to speak with about this. Our app has hundreds of thousands of users that are unable to login currently, our customer service team is completely overloaded and we are out of options. What can we even do? Please help!

I ship a macOS audio player on the Mac App Store. I want to re-enable a remote-control feature, but I got rejected for it once already and I want to avoid burning another review cycle. I'd appreciate guidance from anyone who has shipped this pattern. What the feature does The Mac app runs a small local HTTP server (BSD sockets + GCD) on port 7777 and advertises itself over Bonjour as _tmstudioplayer._tcp. A companion iOS app discovers it with NWBrowser and controls playback: transport, volume, EQ, and so on. Everything stays on the local network. There is no cloud service, no account, no login, and no user data leaves the device. The server only accepts connections while the Mac app is running and in the foreground. This requires com.apple.security.network.server, plus NSLocalNetworkUsageDescription in Info.plist. The rejection An earlier build was rejected because com.apple.security.network.server was declared but App Review could not observe any functionality that justified it. That was fair. At the time the iOS companion app did not exist publicly, so from the reviewer's side the entitlement genuinely looked unused. I removed the entitlement, and the app was approved and is on the store today with the remote feature disabled. The iOS app now exists and works end to end. So I would like to turn the feature back on. The actual problem The feature is, by definition, not demonstrable on a single machine. To see it work, a reviewer needs a Mac and an iPhone on the same local network, with a build of the iOS app installed. As far as I can tell, App Review does not link a macOS app record and an iOS app record so they get reviewed together — they are separate submissions in separate queues. So I cannot simply say "review these two together and you'll see it work." That leaves me guessing at the right approach, and each guess costs a review cycle. What I'm asking What is the correct submission order? Should the iOS companion be live on the App Store first, so I can point to it by name and App ID in the macOS Review Notes? Is a public TestFlight build enough? Does a reviewer even accept a TestFlight link as evidence? Is a demo video sufficient on its own? I can record the full flow — launching the Mac app, the iPhone discovering it over Bonjour, and control working — and attach it to App Review Information. Has that alone been accepted for a local-network feature, or does the reviewer still need to reproduce it? Is there a supported way to point one submission at another? Anything better than a plain-text description in the Review Notes — an App ID reference, a link, an attachment convention that reviewers actually follow? Does a reviewer have a second device available at all? If a two-device local-network setup is simply not something App Review will perform, I'd rather know now and plan around it than assume otherwise. Is there a fallback demo path I'm missing? For example, shipping a loopback/self-test mode in the Mac app that exercises the server on 127.0.0.1 and shows the result in the UI, so the entitlement is demonstrably used without a second device. Would that satisfy the "entitlement must be used" requirement on its own? What I'll do either way If the answer is that this cannot be demonstrated reliably, I'll keep the entitlement out and ship the remote feature only in a direct-distribution (notarized, non-sandboxed) build. I'd just rather not find that out through another rejection. Any first-hand experience with local-network / companion-device features on the Mac App Store would help a lot. Thanks.

Hi. Does anyone know who we can contact about app store reviews taking too long. Our app has been waiting/in review for about two weeks. This is very confusing. We even expedited our build

We are looking for guidance on how to proceed with a repeated App Review rejection under Guideline 5.6 for our iOS app. The review message says the app shows unusual behavior commonly associated with fraudulent activity and that features appeared to be intentionally hidden during review. However, no specific screen, feature, account state, flow, or reproduction steps have been provided despite follow-up requests. The app includes legitimate account-state-dependent flows. Some screens become available only after normal user eligibility is met, such as after a purchase, a savings plan activation, sufficient balance, or a holding period. Examples include transaction history, sell/withdrawal, rewards, and physical delivery. To support App Review, we have already provided two review accounts: one pre-purchase account and one post-purchase account. We have also updated App Store screenshots to cover the major functionality screens and uploaded complete screen-recording videos in App Review Messages for both account states. Both accounts use the same production app, backend, APIs, eligibility rules, and feature configuration as regular users. There are no reviewer-specific permissions, reviewer-only configurations, or hidden feature flags. We do not want to keep resubmitting blindly without understanding what Apple observed. What is the recommended way to obtain a specific issue description or reproduction path for a Guideline 5.6 rejection when the response remains generic? Is requesting an App Review appointment or call appropriate in this situation?

Hello Apple Developer Community, I would like to ask for some advice regarding my app review status. App Name: TopRead Apple ID: 6787079131 Submission ID: 20c08ed4-8199-43da-9521-02d0a0f735ae Here is the timeline: July 22: Submitted my app for App Review. July 30: Received a rejection notice from the App Review Team. July 30: Addressed all the issues mentioned in the review feedback and resubmitted the updated version on the same day. Today: It has been 11 days since the resubmission, and the status is still showing "Waiting for Review". I have also contacted Apple Developer Support regarding this matter (Case ID: 20000122447322). However, the response only mentioned that the app is still waiting in the review queue and did not provide an estimated review timeline. We fully understand that App Review requires time and follows a standard process. However, this extended waiting period is beginning to significantly impact our business operations, release schedule, and user expectations. Since we have already addressed the issues from the previous review and submitted the updated version, we would appreciate any advice from the community or Apple team regarding whether this waiting time is normal, or if there are any recommended next steps we should take. Thank you very much for your time and any guidance you can provide. Best regards, TopRead Team